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Space Station User Documentation: 
Lessons from the Space Shuttle 


FOREWORD 


Users of complex systems are often confronted with a complex array of 
documentation which is essential to understanding and getting the most out the 
system. Space Station users and prospective users will depend heavily upon 
Program documentation to first decide whether and how to use the system, and 
then to guide them through their planning and utilization of a diverse set of 
flight elements, ground facilities, software and data networks. Program-to- 
user documentation will often be the user's most informative interface with 
the Program. The degree to which this documentation is clear, accessible, 
well-organized, accurate, and timely will directly influence the amount of 
user and Program resources needed for effective Station utilization. 


Many users of the Space Transportation System (STS) feel that substantial 
improvements may be made in the way documentation was handled in terms of 
quantity, clarity, and accessibility. In many cases, users have found 
information contained in related documentation to be contradictory. In this 
paper, the results are presented of a survey of STS users about their 
experience with STS documentation. Based on these results and considerable 
thought and discussion of how to streamline the interface between users and 
the Space Station Program, a multi-level Program-to-user documentation 
structure is recommended. Documentation levels are related to increasing 
levels of commitment to using the Station, and permit a prospective user, and 
later an approved user during payload development, to go only as far as a 
well-defined level of documentation to find the needed information. 


Other recommendations are made regarding the accessibility and indexing 
of Station-to-user documentation using the Space Station's computerized 
Technical and Management Information System (TMIS), and regarding the 
submission of User-to-Program documentation in an orderly and non-repetitive 
manner over TMIS. 


It should be understood that not all Shuttle users participated in the 
survey. The valuable results which a broad diversity of users have derived 
from the Shuttle program speak for themselves; any criticisms contained in 
this document are intended in the most constructive possible manner. 


The work described in this document was performed at the Jet Propulsion 
Laboratory for the Level I Space Station Utilization Office at NASA 
Headquarters. People performing the User Services Handbook, User Operations 
Policy, and User Operations Support Definition tasks all provided information 
for this document. 


Robert L. Staehle 
Systems Analysis Section (311) 
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ABSTRACT 


fa This paper reports the results of a survey of Principal Investigators 

| (PIs) regarding their experience with Space Shuttle/Spacelab systems’ 

: Program-to-user documentation. Based on earlier definition and policy studies 
ra at JPL and the survey results, recommendations are made to improve the 
structure and distribution of Space Station Program-to-user documentation. 


RECOMMENDATIONS 


1. The Space Station Program Office must take early action to ensure that 
the Program-to-user documentation structure is comprehensive, concise, 
easily accessible, accurate, and quickly provides the user with all 
appropriate information at different levels of interaction with the 
program. A documentation control plan for all documents needs to be 
developed and implemented by Program management to ensure that documents 
are kept accurate and up-to-date. 


2. The Space Station Technical and Management Information System (TMIS) 
should provide the capability for users to perform keyword searches of 
all available Program documents. A data base should list the contents of 
each document in detail, specify necessary prerequisite documents, 
indicate the date of the last revision, and provide for online ordering 
of printed copies of all documents. 


computer graphic format) of all Program-to-user documentation for 
investigators to download into their computers. TMIS should survey 
potential Space Station customers to determine which graphic standard(s) 
would best serve their needs. 


m 3. TMIS should store the actual text and diagrams (in a standardized 
| 


4. All printed Program documents should be available from a single source. 
i This source should have an adequate staff to respond quickly to requests 
for information and be able to provide copies of the latest update of 
each document from stock. The source organization should be serviced by 
TMIS to take orders for documents directly from the TMIS user. This 
organization's staff should also be well informed as to whether a 
particular document is "the latest" version and whether other documents 
are necessary to support the user's needs. 
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5. All documents should be identifiable by a discrete document number, be 
dated, contain an index, contain a clearly defined scope and purpose, and 
clearly fit into the overall Program-to-user documentation structure. 


| 
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6. An automated log of controlled document recipients should be maintained 
so document users can be issued timely, automatic updates. 


More specific recommendations are made in the sections on Documentation 
Structure and Electronic Distribution. 
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BACKGROUND 


One of the most frequent complaints heard from Shuttle users is the 
proliferation of documentation about the Shuttle system which users must 
obtain and the difficulty of tracking it all down. After documents are 
obtained, many users discover that documents often contradict each other, 
causing unnecessary delay and expense (Ref. 1). To confirm that these 
problems were and are real, and to test reaction to some solutions, Shuttle 
and Spacelab users were asked to complete a brief survey. (For the purposes 
of this paper, a Shuttle/Spacelab "user" is defined as an investigator who 
developed a payload to fly on the Shuttle -- meaning that he employed at least 
some of the available Program-to-user documentation -—- whether or not the 
payload actually flew). Surveys from respondents who acknowledged that they 
did not use STS documentation were discarded. A total of 28 completed surveys 
were tabulated; of those, eight were from users who worked at NASA or NASA 
Centers and 20 were from users in the private sector (industry or 
university). Only North American users were surveyed. Responses are 
tabulated in Appendix A. 


The process of developing payloads is clearly not an easy one, and users 
had documentation problems at the very beginning: they reported that it was 
difficult even finding out which documents they needed. Even NASA-employed 
investigators relied on "word of mouth", personal contacts and research to 
learn of the existence of documents. After the PIs identified the documents 
they needed, they found them difficult to acquire. The documents were 
obtained from a variety of sources, including mission and project managers, 
meetings, program offices, and even "“inter-library loan". 


Once the documents were in hand, there was disagreement on how good they 
were. While there was a consensus that documents were "appropriately 
technical" in nature and that they were generally complete, half of the PIs 
found that there was conflicting information among documents. Some of this 
information is still contradictory, one respondent noted, even after the 
discrepancies were pointed out. Several respondents said the conflicts in 
documents caused them delays or extra expenditures. 


Documents were easier for the PIs to use when they had an index, were 
well written with a clear purpose and scope, were amply illustrated, and 
accurate. Documents were difficult to use when they were out-of-date, didn't 
have an index, had conflicting or unclear information, or were poorly cross— 
referenced with other documents. Other complaints were that there was much 
redundant and irrelevant data, the needed information was spread over too many 
different documents, or it was difficult to determine which document was 
needed. 


It is clear that users were inconvenienced by Program-—to-user 
documentation not being available from a single, centralized source and the 
lack of a cohesive structure to create a linear progression from the 
introductory documents to the specific mission documents. The result of the 
current system is both gaps in the information (especially when the user can't 
determine the existence of a document he needs) and overlaps in documents 
(since the lack of a structure doesn't create a clear scope or purpose for 
each individual document). 


The respondents were unanimous that having a centralized source from 
which they could order any document would be extremely helpful. Also, the 
users were in favor of having a central computerized data base of the 
documents which could be searched by keyword to determine which documents 
would be valuable to them. Finally, users are very interested in having the 
text and diagrams of all documents available online for downloading directly 
to their computers -- a capability that would be in addition to printed copies. 


The Shuttle/Spacelab system was a very complex, intricate system. The 
Space Station will be several times more complex. Since the Shuttle 
documentation structure was clearly a problem for users, it is obvious that 
the Space Station documentation structure must be streamlined and ordered 
before the Program documentation becomes a too-complex system that is not 
serviceable to its users. 


DOCUMENTATION STRUCTURE 


An overall documentation structure has been discussed by members of the 
JPL Space Station User Operations Team, including participants in Program- 
sponsored User Operations Policy formulation, User Operations Support 
definition and the User Services Handbook task. A summary of this structure 
was first published in a description of the proposed User Operations Support 
organization (Ref. 2), and was presented at a review of JPL Space Station 
Utilization tasks by Richard Halpern on January 20, 1987. 


In a recent JPL discussion paper (Ref. 3), seven levels of documentation 
were proposed, with each level appropriate to increasing degrees of 
involvement of a user or prospective user with the Program. These 
documentation levels are: 
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Levels of Documentation 


Level Category/Application 


0 International Agreements: Partner agreements and memoranda of 
understanding. 
1 General Public Information: Wide distribution glossy material for 


anyone having an interest in the Space Station Program. 


2 General Solicitation of User Interest: Marketing-type information 
for soliciting interest from all categories of possible users. 


3 Programmatic Utilization Documentation: Information needed to 
ascertain the utility and competitiveness of the Station for a 
particular application. Permits a prospective user to make realistic 
engineering, financial and management determinations of whether to 
seek Station resources for the performance of a proposed activity and 
to accurately estimate the complexity, schedule and resources 
required to operate a payload using the Station. 


4 Technical Utilization Documentation: Information required to 
develop, test and certify payload equipment, get it launched, 
operated aboard the Station, and returned. 


5 Mission-Specific Documentation: All joint user/Program documentation 
required to plan and conduct successful and contingency payload 
operations during a mission interval. 


6 Experience Documentation: Questionnaires and narratives by users and 
Program personnel who interface with users describing their mission 
experience, with a focus on problems, how they occurred, how they 
were resolved, and how such problems might be mitigated or prevented 
in the ruture. 


The above levels are in general order of increasing detail, but are not 
strictly in the order of when each set of documentation would be provided to a 
specific or prospective user. For example, some mission-specific 
documentation, such as a current payload manifest, might be given to a user 
before issuing detailed interface specifications. These "levels" are not to 
be confused with STS management levels, Spacelab integration levels, or Space 
Station Program levels. There is no connection between the terms. 


CONTENTS OF LEVELS 
Most levels will contain a number of specific documents, all of which are 


related to a particular level of involvement for the user. The following 
documents (or types of documents) are seen as part of each level. 
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Level 0, International Agreements, are public records. Most prospective 
users are likely to be aware of these agreements before ever dealing with 
the Program. International agreements are not really documents supplied 
by the Program to the user, but they provide the foundation for 
agreements and documents that will involve users later in their lifecycle. 


Level 1, General Public Information, will be circulated by a number of 
sources (certainly from each of the Partners), and will consist at a 
minimum of a brochure showing what the Station looks like and summarizing 
its capabilities and benefits. Educational publications, NASA SP-series 
books, and a variety of more specific brochures and booklets would fall 
into this level. 


Level 2, General Solicitation of User Interest, is likely to involve the 
distribution of marketing-oriented documents by the Space Station Program 
Office. An outreach pamphlet and an investigator's guide are presently 
under development under the sponsorship of the Level I Utilization 
Office. User discipline codes might also create "marketing" documents, 
but these would not necessarily be under the direction or sponsorship of 
the Program. 


Level 3, Programmatic Utilization Documentation, is where serious prospective 
users get their first thorough exposure to the Station's capabilities, 
limitations, and the responsibilities of the Program and users. This is 
where an organized structure and a coordinated dissemination method begin 
to truly benefit the prospective user. The documentation in this level 
describes the Space Station Program, gives a summary of how the Program 
is organized, who the Partners are, what the partners’ various ownership 
interests and responsibilities are, and how the different parts of the 
Program and outside organizations (such as contractors, NASA codes, and 
Partner agencies) interact. Prospective users need to have this 
information to effectively navigate through the Program and to understand 
what different people are telling them. No such organized summary is 
presently provided to prospective Shuttle users, though the information 
can be gleaned from a number of sources. 


Level 4, Technical Utilization Documentation, includes very specific 
information about standardized elements, services and utilities. 
Documents dealing with exact interface specifications, subsystem 
descriptions, operational requirements and safety requirements would be 
included in this level. 


Level 5, Mission-specific User/Station Documentation, includes mission 
manifests, requirements for compatibility with other payloads, 
integration plans, and other custom-generated documents for each mission 
interval. As the mission nears its start date, such documents may change 
as often as daily and may only be available online through IMIS. 


Level 6, Experience Documentation, would be completed by the user after the 
end of his mission interval. It would describe successes, failures, and, 
most importantly, the lessons learned that might benefit future users. 


DOCUMENTATION CONTROL 


For each document within this structure (including any added later), an 
originator and control point needs to be specified. Different portions of a 
particular document may originate from several offices, in which case multiple 
levels of control may be required (perhaps through a normal hierarchical 
signature tree) leading up to the single office responsible to the rest of the 
Program for origination and maintenance of the document. 


The originator of each document should be responsible for that document's 
maintenance throughout the life of the Program, as all documentation will need 
to be updated from time to time. Accurate and timely updates will be 
especially important for documentation specifying user interfaces and for all 
mission-specific documentation, the latter of which may change on a daily 
basis. 


All Program-supplied documentation needs to be consistent to avoid user 
confusion and surprises for system operators. There may need to be a high 
level “consistency control point" responsible for all Station-to-user 
documentation. This should be considered as a possible responsibility for 
some part of a User Operations Support organization, which could remand 
conflicting language to the originators and their respective control points 
for removal of any inconsistency. For example, a safety document might 
specify a peak load of 5 amperes for a particular type of electrical connector 
while an interface specification document might cite a peak load of 4 
amperes. Both might be ambiguous regarding the meaning of “peak load", with 
the writers of the safety document meaning instantaneous load and the writers 
of the interface specification meaning loads lasting for less than 30 
seconds. The manager responsible for consistency control would direct that 
the two groups of originators work out a solution to make the two documents 
consistent. Upon agreement of the two originators, any control points between 
them, and the top-level consistency control point, one or both documents would 
be changed as agreed to make the documents consistent. 


It is doubtful that any consistency check will be absolutely thorough. = 
Therefore, users and other people who work with the documents are likely to 
find occasional inconsistencies. A very simple and clear method should be 
established for reporting such inconsistencies, or even portions of documents 
which are simply confusing. This could take the form of a "tear out" one-page 
problem report in each document which lists the address and telephone number 
of the office responsible for consistency control. Rapid problem reporting 
should be encouraged with reporting to a single collection point. As we have 
seen at JPL (Ref. 1), users can spend a great deal of time and money building 
hardware to a particular documented specification which they believe to be 
accurate, only to find out at the launch site that the specification was 
incorrect, requiring a costly delay or a hasty reconfiguration. Consistency 
control would review each reported problem, determine if corrective action is 
necessary, and notify the user of the result of his criticism. 


Finally, to facilitate the exact identification of various documents, 
each discrete publication should be issued a document number by the 
consistency control point. Each document, and preferably each page in 
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rapidly-changing documents, should be dated so it is clear to the reader which 
particular version is the most recent. In addition, a printed list of all 
documents should be published for the users. 


ELECTRONIC DISTRIBUTION 


Survey results show that users are enthusiastic about having a detailed, 
keyword-searchable online listing of all available user documents. This 
searching could be used to determine which documents are required. For 
example, a materials processing experiment investigator could enter the key 
"toxic substance" and get a complete list of documents describing safety 
requirements for the handling of toxic reagents. Cross-referencing might 
suggest to the investigator that he needs to review documents describing 
special launch vehicle requirements for hazardous materials, waste containment 
systems, etc. 


Additionally, these survey respondents agree that the storage of the 
actual text and diagrams from these documents online (in a specific, 
standardized computer graphics format) to allow immediate downloading into 
their computers would be very helpful. While most users will want to have 
printed copies of most documents, having the latest versions available online 
would allow a user to immediately access updates. For example, if a user is 
building his payload and discovers that the diagram on an electrical interface 
connector is ambiguous or out-of-date, he could access the interface document 
online and download the section, with diagrams, that deals with the connector 
in question. This capability could save countless hours or days of waiting 
for updates -- and the associated costs involved. 


The Technical and Management Information System (TMIS), which is 
currently being implemented, will tie together all NASA centers and all Space 
Station users. Such a widely available network would be an ideal place for 
the online documents to be stored. TMIS planners, during their fact-finding 
interviews at NASA centers, have been informed that this type of documentation 
support would be useful. MIS already has plans for the graphic capabilities 
necessary to store document diagrams and illustrations. The system should 
also be able to log orders for specific documents; such orders should be 
filled from the source without further effort by the user. 


These requirements should be quite easy to fulfill, considering the 
current state of commercial computer network services. For example, the Dow 
Jones/News Retrieval Service and the CompuServe Information Service each have 
several hundred thousand subscribers who can use the service's standardized 
front end to search through numerous databases and download text and graphics 
using a number of error-resistant protocols. 


USER-TO-—PROGRAM DOCUMENTATION 


In addition to finding Program-to-user documentation online, users should 
be given the capability to transmit user-to-Program documentation via IMIS. 
This could be facilitated by "interactive documentation" approaches where the 
user would answer online questionnaires or utilize text generators to create 
standardized documents (the Payload Integration Plan (PIP) is a prime example 
of such a "boilerplate" document). Printed copies would then be generated for 
formal approval and signatures. 
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The implementation of a "payload engineering database" on IMIS would 
allow users to submit technical design and operations information in one 
format and only one time. Once submitted, different parts of the Program 
would then be able to access (with appropriate protection of confidentiality) 
specific information they need without requiring additional input from the 
users. 
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: APPENDIX A 
Survey and Responses 

Note: Not all answers add up to the total number of respondents. Non- 
responses were not recorded; answers to open questions (such as "what 

i made documents more useful") sometimes had several responses -- all 
of these were recorded. Some comments are paraphrased, but reflect 
the respondents' intentions. 

: Total Responses: 

fm NASA PIs /8 


a Non-NASA PIs /20 
Number which requested summary of findings: 


{ NASA PIs /4 
Non-NASA PIs /12 
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Questions 


re 1) Did you find that STS documentation, in general, was complete? Were all 
the topics you needed information on covered in sufficient detail? 


pe Yes /22 
l -- but it was spread over too many documents /2 
-- but not easily understood /2 
ia -- but the information is so scattered, it is difficult to find specific 
| references 
-— but we also could have used an approved materials list 
rm -- but it was not kept up-to-date 
| -— the documentation may be complete, but is chaotic. Needed info may be 
contained in the document but it is not easily picked out 
-- but further telephone clarification was frequently required 
rm -- but only if you know in advance what to look for 


No /4& 
[™ -—~ not sufficient on coordinate systems and positions of remote manipulator 
t arm. Not good on OANC tapes 
~- background operational information was often fragmentary and confusing 
but this has probably improved since our early flight 
-- some particular information was lacking 
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2) Did you find that information in documents was generally 


Needlessly technical /4 
Appropriately technical /19 
Not technical enough /1 


i 


3) Did you ever find conflicting information in documents that caused 
problems for you? Did those problems cause delay or extra expenditures? 
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/13 

-- conflicting information did cause extra delay and expenditure /2 

-- though the conflicts didn't cause problems /2 

usually had to verify with MSFC, which caused delays 

some is still contradictory even though contradictions were pointed out 

-- there were several occasions when the description from the control 
document differed from the instructions from the payload ops group 

-- considering the scope of the documentation, I think they've done well in 
this area 

-— much too much overlap in documents, causing extra expenditure in 
resolving conflicts 

-- especially if you weren't careful to keep up-to-date 

-- especially between NASA centers 
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No /13 
-- but insufficient information and TBDs caused delays 
-- but only if you were sure to have the latest updates 


ee 
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4) In general, what made documents more useful? 


Well written /6 

An index /5 

Good introductory material /3 
Illustrations /3 


Accurate 
a Good descriptions 
ig Complete table of contents 
L 


Listing of contact personnel who could clarify ambiguities 
Clear statement of purpose and scope 


" Status of revision 
A NASA-assigned “book manager" 
Examples 
ia Less emphasis on “NASA idioms" 
i ooo 


5) In general, what made documents difficult to use? 


: Too much irrelevant data /6 
Info contained in too many different documents /4 


fe Too many PIP annexes /2 

| Not clear whether document was current or not /2 
Change control difficult to follow /2 

pa Too many acronyms /2 . 

Bulky size /2 

: Ambiguous language /2 

Out of date 

No (or poor) index 

Conflicting/unclear information 

Lack of a central distribution point for documents 

fas Too many TBDs 

| Poor cross-referencing 
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Not written with the reader in mind 

Difficult to get late changes in payload accommodations documentation 

Frequent changes impacted already completed work 

The multi-level paragraph numbering system (eg 3.4.42.7.80...) 

Didn't contain the data they were supposed to 

Our main document wasn't completed by the time we needed it 

Large number of updates 

Difficult to understand the document hierarchy 

Too much needless jargon 

Not written with the user's requirements in mind 

Contradictions between documents 

Finding the right document 

Different documents from different centers use their own conventions, making 
the documents inconsistent in presentation 

Other documents were referenced only by number, making it difficult to 
determine whether they were needed or not 
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6) Where did you find out about which documents you needed? 


Miscellaneous NASA personnel /9 

Cross reference from other documents /6 

-- but this is insufficient 

Program or project office /5 

Payload Integration Manager /4 

Launch Site Support Manager /2 

Investigator's Working Group (IWG) meetings /2 
—- it was too casual; I didn't get all required documentation 

Word of mouth 

Miscellaneous NASA personnel 

Technical monitor 

HQ Customer Services Rep 
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7) How did you obtain the documents you needed? Was the documentation you 
needed easy to obtain? 


Miscellaneous NASA personnel /6 
-- but some people tend to be quite possessive of large, important, hard to 
obtain documents 
-—- we didn't always get the documents we asked for 
PIM/LSSM /4 
-—- documents were easy to obtain, but I had to generate most of the 
technical detail myself 
Easy to find once you knew what you needed /4 
Ordered from JSC /3 
——- but we often didn't get what we ordered 
-- usually received documents within a week 
NASA Program Office /2 
-- this sometimes was time-consuming 
IWG meetings /2 
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Project or mission manager 
-—- but docs were not easy to obtain 
Through inter-library loan 
—- this was not an easy process 
Not sure how we got them, but we did get them fairly easily 


8) Would it be helpful to you if all documentation was available from a 
single source? 


Yes /22 

-—- this is imperative /3 

— but would not be good for flight operations documents 
-—— but I don't think it's likely to happen 

—- especially when you want to update distribution lists 


Probably /5 

-- needs to be well-organized to respond quickly 

-- but it would be equally helpful if several different organizations had 
documents if they all followed similar procedures 


9) Were you aware of exactly what documentation was necessary or required 


reading? 
Yes /8 
-- but personal contacts were essential to determine which documents were 
applicable 


-—- but we only really used one main document (SPAH) 
—— but a long, tedious learning process was required 
-- but it required some consultation to be sure 

-—- but only after research 


No /20 
-— but it got easier when we gained experience 
——- since no effort was made to provide us a list of documents 
-- but I think this is improving 
-- I still don't know 


me 


10) Would it be helpful to you if there were an indexed list of available 
documents online in a database? 


Yes /24 
—- also should have summary or abstract /5 
-—- this is imperative /2 
-—— should also be available in printed form /2 
-- this would be extremely helpful 
—- but not especially helpful for me 
-- the database must be kept up-to-date 


Probably /2 
-— at least a printed list is necessary 
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Would it be helpful to you if the actual text of the latest versions of 
each document was on line, available for downloading to your computer? 
/22 


but only if in addition to paper form /3 

all users should be given access; on STS, passwords were often changed 
without notification 

but we are concerned about downloading time which may be necessary 
this would be most helpful 

this is imperative 

but not especially helpful for me 

may be impractical 

a great idea 


Probably /2 


No /3 


12) 


What comments and suggestions do you have to help make future Space 
Station documentation more useful? 


Reduce the number of documents /4 
Have specialists available for telephone consultation /3 
Publish an introductory document which guides the user through needed 


documentation and references /3 


Have documents available online /2 

Publish a list/index of all documents /3 

Simplify the language used /2 

Better documentation structure/organization /2 

Should be uniform in design and use /2 

Have all documents available from a single source /2 

Documents should be issued in loose-leaf form and be frequently updated with 


update pages 


Replace entire document rather than issue update pages 
Issue updates in a timely manner 
Computer indexing of documents for searching on a particular topic 


Use 


an easier-to-read typeface 


Make it clear what documents are needed and how to get them 

Keep them up-to-date 

Make them more easily available 

Listen to the problems we have outlined in the past 

Better guidelines for which materials are approved 

Categorize and simplify as much as possible 

Have indexed database available 

Publish an easy-to-use guide to all documentation and send it to everyone 


13) 


Please list (on the reverse or on a separate page) the primary STS 
documents which you used in preparing your payload for flight aboard the 
STS. If appropriate, note those documents which you found most helpful 
or difficult, and why. 


(responses not tabulated) 


14 


14) Would you be interested in providing more detailed information in a 
telephone or face-to-face interview? 


Yes /12 
No /9 
-—- not enough time! 


-- too busy doing NASA paperwork 
—- I don't think I would be helpful 
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